Skip to content

Moved Foundation to AWSLambdaRuntime; AWSLambdaRuntime renamed to AWSLambdaRuntimeCore #41

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
May 7, 2020

Conversation

fabianfett
Copy link
Member

@fabianfett fabianfett commented Mar 14, 2020

Motivation

  • This PR shall remove the use of Foundation from AWSLambdaRuntime so that AWSLambdaRuntime doesn't link Foundation anymore
  • We do this so others can overload the run method with their Codable implementations. Otherwise custom implementation always need to have a name other than run. Compile error: "Ambiguous use of 'run'"
  • Currently there is one last use of Foundation: JSONEncoder is used within LambdaRuntimeClient. Addressed in Remove use of JSONEncoder for Error Reporting #42.

Changes

  • Created target AWSLambdaRuntimeFoundationCompat
  • Moved Lambda+Codable into AWSLambdaRuntimeFoundationCompat
  • added a property deadlineDate to Lambda.Context that returns the deadline as a Foundation.Date

Open ends

  • Do we want to @_exported import AWSLambdaRuntime within AWSLambdaRuntimeFoundationCompat? So developers don't have to go:
import AWSLambdaRuntime
import AWSLambdaRuntimeFoundationCompat
import AWSLambdaEvents
  • Do we want to support a DataLambdaClosure/DataLambdaHandler? With this we could eliminate the need to understand ByteBuffers for less experienced developers.

@fabianfett fabianfett force-pushed the foundation-compat branch 3 times, most recently from 55b5dd3 to 32de43b Compare March 15, 2020 10:41
@fabianfett fabianfett mentioned this pull request Mar 17, 2020
@tomerd
Copy link
Contributor

tomerd commented Mar 18, 2020

hey @fabianfett I think the goal of not linking foundation is a good one if we cannot get the performance we need with static linking.

I also like the idea of being able to use alternative encoder/decoders, tho overriding encoding/decoding behavior is already possible with the current API, eg:

struct Handler: EventLoopLambdaHandler {
    // the normal handler
    func handle(context: Lambda.Context, payload: Request) -> EventLoopFuture<Response> {
      ...
    }
    
    // override the default encoding behavior
    func encode(allocator: ByteBufferAllocator, value: Response) throws -> ByteBuffer? {
      ...
    }
   
    // override the default decoding behavior
    func decode(buffer: ByteBuffer) throws -> Request {
      ...
    }
}

one idea I did not explore too much and maybe worth looking into is keeping all the Codable APIs in place but allowing the users to inject an alternative TopLevelEncoder/TopLevelDecoder instead of JSONEncoder/JSONDecoder as another way to achieve the override above.

the one thing I am not convinced about is separating the modules like this, it does not feel like a good step from a usability point of view. in practice, I believe most/all invocation use-cases will be JSON based (as shown in #35) which means users are most likely always import AWSLambdaRuntimeFoundationCompat instead of import AWSLambdaRuntime and that seems a bit awkward to me. do you think that most cases will not be JSON based?

@fabianfett fabianfett marked this pull request as draft April 14, 2020 20:51
@fabianfett fabianfett force-pushed the foundation-compat branch 2 times, most recently from 3627846 to 633c829 Compare May 1, 2020 11:26
@tomerd
Copy link
Contributor

tomerd commented May 7, 2020

@fabianfett as discussed, lets

  1. rename AWSLambdaRuntime to AWSLambdaRuntimeCore`
  2. rename AWSLambdaRuntimeFoundationCompat to AWSLambdaRuntime
  3. have (new) AWSLambdaRuntime export AWSLambdaRuntimeCore

@fabianfett fabianfett force-pushed the foundation-compat branch 2 times, most recently from aff9c26 to 09768ec Compare May 7, 2020 08:12
@@ -12,6 +12,7 @@
//
//===----------------------------------------------------------------------===//

@_exported import AWSLambdaRuntimeCore
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tomerd do we want this here? Use an extra file?

self.run(configuration: configuration, factory: { $0.makeSucceededFuture(handler) })
}

// for testing and internal use
@discardableResult
internal static func run(configuration: Configuration = .init(), factory: @escaping (EventLoop) throws -> Handler) -> Result<Int, Error> {
public static func run(configuration: Configuration = .init(), factory: @escaping (EventLoop) throws -> Handler) -> Result<Int, Error> {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tomerd we need to pay intention here. This is a change, that I made to make it work fast... But this is needed if we want to be able to test with config for codable as well.

My idea would be to keep this private and really just test the codable closure. Anything else should already be tested by the string tests.

@fabianfett fabianfett force-pushed the foundation-compat branch 2 times, most recently from d342138 to b96da08 Compare May 7, 2020 08:52
@fabianfett fabianfett changed the title Moved Foundation to FoundationCompat lib Moved Foundation to AWSLambdaRuntime; AWSLambdaRuntime renamed to AWSLambdaRuntimeCore May 7, 2020
@fabianfett fabianfett marked this pull request as ready for review May 7, 2020 08:53
@fabianfett fabianfett requested a review from tomerd May 7, 2020 08:53
Copy link
Contributor

@tomerd tomerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks good but i feel we list allot of testing, is that part of the change necessary?

@fabianfett
Copy link
Member Author

overall looks good but i feel we list allot of testing, is that part of the change necessary?

@tomerd Yes, it is either this, or we make these functions public:

// for testing and internal use
@discardableResult
internal static func run(configuration: Configuration = .init(), handler: Handler) -> Result<Int, Error> {
    self.run(configuration: configuration, factory: { $0.makeSucceededFuture(handler) })
}

// for testing and internal use
@discardableResult
internal static func run(configuration: Configuration = .init(), factory: @escaping (EventLoop) throws -> Handler) -> Result<Int, Error> {
    self.run(configuration: configuration, factory: { eventloop -> EventLoopFuture<Handler> in
        do {
            let handler = try factory(eventloop)
            return eventloop.makeSucceededFuture(handler)
        } catch {
            return eventloop.makeFailedFuture(error)
        }
    })
}

@fabianfett fabianfett force-pushed the foundation-compat branch from b96da08 to ede1bed Compare May 7, 2020 15:51
@tomerd tomerd merged commit 1d96372 into master May 7, 2020
@tomerd tomerd deleted the foundation-compat branch May 7, 2020 16:37
tomerd pushed a commit that referenced this pull request May 7, 2020
…LambdaRuntimeCore (#41)

motivation: enable non-foundation module for performance sensitive use cases

changes: 
* rename AWSLambdaRuntime to AWSLambdaRuntimeCore 
* create AWSLambdaRuntime for Foundation dependent functionality 
* have (new) AWSLambdaRuntime export AWSLambdaRuntimeCore
* adjust tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants